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(54) An arrangement for dynamically deriving a telephone network management database 
from telephone network data 



(57) A network management facility is adapted so 
that it obtains information including connectivity data as 
well as the identities of discrete network elements from 
an associated network and then uses the information to 
determine the configuration of the network. The manage- 
ment facility then generates, for storage in a network 
management database, data records characterizing the 
configuration of the network, as defined by the compo- 
nents, circuits, etc., forming the network. Once the data- 
base has been created in this manner, the network man- 
agement system may then use the contents of the data- 
base to provision requests entered by network users, for 
example, a request for additional transmission band- 
width. The database may also be used to evaluate a net- 
work condition, such as a condition characterized by a 
trouble alarm. Further, the network management system 
automatically updates the contents of the database to 
reflect a change in the associated network, thereby elim- 
inating the need to rely on personnel to perform that task. 
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Description 

Field of the invention 

The invention relates to determining dynamically the 
configuration of a telephone network for network man- 
agement purposes. 

Background of the Invention 

A network management database typically contains 
a model of the configuration of an associated network 
that may be used to (a) isolate faults in the network by 
analyzing network alarm and event messages and (b) 
provision network services. Such a database is usually 
characterized by a plurality of data records defining re- 
spective objects (e.g., equipment, circuits, transmission 
facilities, etc.,) composing the network. The data con- 
tained in the records is usually derived manually using 
other data records that are stored in databases associ- 
ated with respective Network Elements (NE) forming re- 
spective sections of the network. Telephone personnel 
use the data that is stored in the NE databases and their 
knowledge of the network to manually construct and up- 
date the contents of the records forming the network 
management database. It can be appreciated that if the 
content of a network management database is not kept 
current, then the efficiency of repairing faults and provi- 
sioning of services may be degraded. Moreover, the task 
of manually creating and maintaining such a database is 
labor intensive. 

Summary of the Invention 

The invention in accordance with claim 1. 
Brief Description of the Drawing 

In the drawing: 

FIG. 1 illustrates a telecommunications network in 
which the principles of the invention may be prac- 
ticed; 

FIGs. 2 through 6 illustrate in flow chart form the pro- 
grams which implement the principles of the inven- 
tion in the network of FIG. 1 ; 

FIG. 7 is a simplified block diagram of a network ele- 
ment of FIG. 1; and 

FIGs. 8 and 9 illustrate examples of the data records 
that are stored in the database of FIG. 1 . 

Detailed Description 

Turning now to FIG. 1 , there is shown an illustrative 
embodiment of a telecommunications network 100 that 



is formed from a number of Central Offices (CO), three 
of which are shown in FIG, 1 , namely COs 1 10, 120 and 
1 30. The COs are interconnected via respective commu- 
nications paths to provide for the exchange of commu- 

$ nications. One such communications path that may be 
used to interconnect Central Offices (CO) 110, 120 and 
1 30 as an interoffice network is optical fiber. Accordingly, 
the claimed invention will be discussed in the context of 
the channel capacity of optical fiber. However, that 

10 should not be construed as being a limitation of the 
claimed invention, since the claimed invention may be 
readily used in conjunction with networks that are inter- 
connected via some other transmission media, e.g., 
coax cable. 

*5 Continuing, network 100, comprising COs 110, 120 
and 130, operates to transport a large amount of data at 
a very high rate of speed between access networks. To 
do so, COs 1 1 0, 1 20 1 30 are interconnected via respec- 
tive optical fiber pairs 105-1 , 105-2 and 105-3, in which 
20 a pair of such fibers may operate at a very high trans- 
mission rate, for example, the transmission rate that is 
associated with a Synchronous Optical NETwork (SON- 
ET). Each CO may thus include a lightwave multiplexer, 
which may be, for example, the model FT2000 G light- 
2S wave multiplexer available from AT&T, to switch informa- 
tion arriving via an incoming circuit (channel) of an optical 
fiber to an outgoing circuit (channel) of another optical 
fiber. For example, multiplexer 131 may be arranged to 
switch data traffic received via a circuit, or channel, of 
30 optical fiber pair 105-2 to a channel of optical fiber pair 
105-1 for delivery to CO 120 and thence to a particular 
destination, e.g., access network 200. When such infor- 
mation is received at a multiplexer, e.g., multiplexer 121 
via path 105-1, then multiplexer 121, in a conventional 
35 manner, switches (i.e., "drops") the traffic at a particular 
rate, for example, at a DS3 rate, to multiplexer 201 , which 
may be considered to be an element of access network 
200, in which network 200 (as well as network 300) may 
be, for example, the model DDM2000 multiplexer also 
40 available from AT&T. Assuming that the ultimate desti- 
nation of such traffic is Customer Premises Equipment 
75, then Multiplexer (MUX) 201 multiplexes the traffic 
arriving at a DS3 rate to a channel having a higher ca- 
pacity, e.g., a 155.52 Mb/sec channel, for transport to 
45 hub MUX 202. MUX 202, in turn, transports the traffic to 
MUX 204 at the same rate for delivery to CPE 75 at one 
of a number of different rates controlled by the CPE, for 
example, a DS 1 rate. Information received from CPE 75 
is transported to CO 120 in a similar manner but in an 
50 opposite direction. 

Traffic that is destined for either CPE 25 or CPE 50 
is similarly transported over interoffice network 100 and 
supplied to access network 300 in a similar manner. In 
contrast to access network 200, however, access net- 
55 work 300 is configured as a conventional ring network 
formed by access multiplexers 302 through 304 and in- 
cludes access multiplexer 301 . Thus, an access network 
may be configured as a hub network, e.g., network 200; 
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ring network, e.g., network 300; linear chain (not shown), 
etc. Briefly, a hub network may be defined as a network 
in which one Network Element (NE) (hereinafter also 
MUX) has three or more NEs as neighbors, i.e., the hub, 
and all of the other NEs have just one neighbor. A simple 
ring network, on the other hand, may be defined as a 
network in which each NE has two neighbors and linear 
chain network may be defined as a network in which the 
NEs at respective ends of the chain have just one neigh- 
bor and all of the other NEs in the network have two 
neighbors. 

Over the course of time the configuration of a par- 
ticular network, e.g., an access network, may change. 
Such a change may occur for a number of different rea- 
sons. For example, the number of elements forming an 
access network may increase as a result of adding an 
access multiplexer thereto, or the number of DS1 circuits 
needed by a particular CPE may either increase or de- 
crease. Moreover, the configuration of the interoffice net- 
work may also change. For example, the interoffice net- 
work may grow as a result of connecting a new CO via 
an associated lightwave multiplexer to the network. 

As part of the management of a network, the config- 
uration and identity of each of the components forming 
the network (e.g., multiplexers, transmission circuits and 
other equipments) are stored in a database, e.g., data- 
base 160 controlled by network management system 
150. This is done so that an associated network man- 
agement system 1 50 may identify, for example, which 
components are idle and which components are being 
used in a circuit assigned to a respective CPE. Thus, 
when a particular customer requests, for example, an in- 
crease in the bandwidth of a transmission channel serv- 
ing an associated CPE, then Network Management Sys- 
tem (NMS) 150, based on its knowledge of the current 
configuration and capacity of the network, may assign 
idle channel capacity to that CPE. Priorly, the task of up- 
dating a network management database to ensure that 
the data stored therein was current was done manually 
as the configuration of an interoffice network or access 
network changed. It can be appreciated that as a result 
of performing that task manually, it is likely that the con- 
tents of the database would not be current and, in certain 
instances, possibly incorrect, it can also be appreciated 
that such a task is labor intensive. 

To deal with that problem, we have recognized that, 
in accord with an aspect of the invention, a knowl- 
edge-based system may be used to identify discrete el-, 
ements of a network including multiplexers, transmission 
circuits, etc., and thus derive the configuration of the net- 
work. The knowledge-based system may, in accord with 
another aspect of the invention, generate data records 
identifying such elements and configuration for storage 
in database 160 so that they may be readily accessed 
by management system 150 for the foregoing reasons. 
Once the database is populated in this manner, then its 
contents may be readily updated in the same manner, 
as will be discussed below. Accordingly, the task of man- 



ually creating and updating a telecommunications net- 
work management database may be virtually eliminated. 

The foregoing may be achieved by arranging Net- 
work Management System (NMS) 150 so that it commu- 
s nicates with each network that it supports to identify, inter 
alia, the elements forming the network, and for each such 
element (a) the way it is equipped, (b) its neighbors and 
(c) its configuration. Based on that information, NMS 1 50 
may then determine, in accord with an aspect of the in- 
vention, the interconnections between neighboring ele- 
ments and the configuration of the associated network. 
NMS 150 may then store data indicative of such identi- 
ties, interconnections and configuration in its associated 
database 1 60. Thereafter, NMS 1 50 may update the da- 
tabase automatically whenever the configuration of the 
associated network changes, in which the change may 
occur as a result of : for example, a particular customer 
request, e.g., a request entered by CPE 25, 50 or 75. 

More specifically, NMS 150 communicates with a 
network, e.g., network 100, via one of the network mul- 
tiplexers that may be optionally designated as a network 
gateway for the purpose of interfacing with NMS 150. It 
is assumed for illustrative purposes that MUX 111 is des- 
ignated the gateway for network 100. To that end, MUX 
111 may communicate with NMS 150 via communica- 
tions path 1 51 -1 using, for example, the well-known X.25 
data communications protocol or any other protocol sup- 
ported by the network elements. It also assumed that 
MUX 201 and MUX 301 are designated the gateways for 
networks 200 and 300, respectively, and communicate 
with NMS 150 via paths 151-2 and 151-3, respectively. 

When a MUX, e.g. MUX 111, Is designated as the 
gateway for its associated network, it then becomes re- 
sponsible for monitoring a particular transmission chan- 
nel (e.g., a so-called overhead channel) provided by the 
associated transmission media, e.g., communications 
path 105, for messages that may be generated by an- 
other element of the same network. Such a message 
may contain configuration, alarm, or event data indica- 
tive of the operational state of the element that generates 
the message. The gateway MUX then reformats the 
message for transmission over the X.25 communica- 
tions path that connects the Gateway MUX to NMS 1 50, 
e.g., path 151-1. 

Assume now that a new access network, e.g., net- 
work 300, is being built and is to be connected to inter- 
office network 100 in the manner shown in FIG. 1. As the 
network is being built and as each new access MUX 302, 
303 or 304 is connected to the network, it is initialized in 
accord with conventional procedures. Such procedures 
include, for example, the storage of an initial cross-con- 
nect map in memory internal to the new access MUX. As 
is well-known, a MUX uses an associated cross-connect 
map to determine the routing of data traffic through the 
MUX, i.e., from an input port (circuit) and associated 
channel to an output port and associated channel. Ac- 
cordingly, when the MUX receives data via a particular 
incoming channel, it uses its cross-connect map and ad- 
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dress of that channel to translate the address of the input 
port and address of input channel into the address of an 
outgoing port and channel to which the data is to be for- 
warded. The MUX then forwards the data toward its in- 
tended destination via the identified output port and 
channel. It is noted that a cross-connect map is associ- 
ated with a particular data rate, which means that a plu- 
rality of cross-connect maps may be associated with re- 
spective data rates, e.g., SONET, VT1.5, STS1, etc., 
DS1, DS3, etc. In that case, then, such maps would be 
stored in the memory of each network element, e.g., 
MUX 304, of the associated network processing those 
data rates. 

The above-mentioned initialization procedure also 
activates system software that directs the overall opera- 
tion of the M JX including the transmitting of administra- 
tive and routing information to the other elements of the 
network. Such administrative information includes the 
identity of the new MUX. Accordingly, then, when a new 
access MUX, e.g., MUX 304, is connected to its associ- 
ated network and then activated, it broadcasts its identity 
over both directions of the ring network to the other ele- 
ments of network 300. When a priorly activated MUX, 
e.g., MUX 303, receives the message, it stores the iden- 
tity in its internal memory and notes the value of a 
so-called "hop count" (or relative network position) con- 
tained in the message, in which the contents of the mes- 
sage is indicative of the position of the new MUX 304 in 
network 300. That is, if the message indicates that the 
receiving MUX is a neighbor of the newly added MUX 
304, then the receiving MUX notes that fact in its internal 
memory. The receiving MUX then transmits the message 
over the overhead channel of each outgoing communi- 
cations path. When all of the network elements (MUXs) 
have been installed - interconnected to one another and 
initialized indicating that the network is ready to be 
placed into service - then an administrator designates 
one of the access MUXs of network 300 as the gateway 
and connects that MUX to NMS 150 via data path 151. 
Inaddition, the administrator notifies NMS 150 of the new 
network and stores information defining the network ad- 
dress, identification and password of the newly designat- 
ed gateway in database 1 60. 

(It is noted that the gateway element (MUX) associ- 
ated with the newly added MUX also receives the identity 
message via the associated overhead channel and 
stores that information in its memory. The gateway MUX 
may then send a message identifying the new MUX to 
NMS 150. NMS 150, in turn, may then send a message 
to the newly identified MUX requesting further identifica- 
tion of the element and a copy of its cross-connect map. 
NMS 150 may also request copies of the cross-connect 
maps stored in the other elements of the network. This 
procedure may be invoked in other instances, such as 
when a new transmission media is placed into service.) 

In response to such notification, NMS 150 invokes 
a process that, in accord with an aspect of the invention, 
builds a model of network 300 and stores the model in 



database 160. MS 1 50 thereafter updates the model as 
the new network changes and uses the model to support 
the operations of the new network, including the provi- 
sioning of transmission circuits in response to a custom- 

5 er request. Such a model comprises a data record for 
each circuit, transmission channel, network element, 
etc., that form the respective network, as mentioned 
above. (An example of such data records are shown in 
FIG. 7 as will be discussed below.) 

io The process that is used to acquire such information 
for storage in database 160 is actually composed of a 
number of subprocesses. A first subprocess, more par- 
ticularly, identifies, inter alia, the (a) elements forming a 
network, e.g., network 300, and (b) transmission facilities 

15 connecting each pair of network elements (neighbors). 
The first subprocess then uses the information it ac- 
quires to derive the configuration of the associated net- 
work and connectivity between the network elements. A 
second subprocess then obtains a copy of the cross-con- 

20 nect map of each network element for each transmission 
rate handled by the network element. The second sub- 
process then uses the (a) cross-connect maps, (b) 
well-known standards for SONET channel mapping, and 
(c) network connectivity derived by the first subprocess 

25 to derive the way in which each transmission circuit 
traverses the network via respective network elements 
and transmission paths. 

Specifically, the network administrator notifies NMS 
150 via terminal 140 whenever (a) an element is added 

30 to a network or (b) a new network, e.g., network 300, is 
installed and activated, as mentioned above. In doing so, 
the administrator supplies the address of each new- 
ly-added element and the password that NMS 150 may 
use to communicate with the associated gateway ele- 

35 ment via the path 151 connecting to that gateway. NMS 
150, responsive to such notification, enters the process- 
es that, in accord with an aspect of the invention, deter- 
mine dynamically the indentity and configuration of each 
such newly-added element and stores the result of the 

40 determination in database 160, as illustrated in FIGs. 2 
through 6. Specifically, when the process is entered, it 
proceeds to block 1, FIG. 2, where it sends a message 
via the particular path 151 to the pertinent gateway ele- 
ment requesting the identities of the other elements 

45 forming the newly-installed network, e.g., network 300, 
the identities of the gateway's neighboring elements and 
address of the port circuit board slots that are used to 
connect the gateway to those neighbors. Upon receipt 
of that information from the gateway, e.g., MUX 301 , the 

50 NMS 150 process proceeds to block 2 where it sends a 
message to each of the identified network elements 
(e.g., elements 302-304 of network 300) via path 151-3 
and gateway 301 to obtain from each of those elements 
the identities of their neighbors and equipment slots of 

55 the port circuit board that are used to connect to the iden- 
tified neighbors. 

The program then proceeds to block 3 where it 
stores the information that it obtainsf rom each of the net- 
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work 300 elements in database 160. The program then 
proceeds to block 4 where, starting from the gateway el- 
ement 301 and for each of its neighbors, the program 
determines the configuration of the newly-installed net- 
work. In the present example of network 300, the pro- 
gram will determine that the configuration of that network 
is a ring. The program does this by linking the neighbor 
information that it obtains from each of the elements 
forming network 300. (Similarly, if network 200 were the 
newly- installed network, then the neighbor information 
would indicate that the configuration of that network com- 
prised a hub. In that case then, the program would assign 
a relative position that each element, e.g., MUX 203, has 
in the network with respect to the gateway and then store 
that information along with with the type of network con- 
figuration for network 200 in database 1 60. ) The program 
then proceeds to block 5 following the foregoing. At block 
5, the process stores in database 160 and for each ele- 
ment of network 300 the address of each circuit slot that 
connects to an external element, e.g., another network 
or CPE. The program (block 6) then obtains from each 
MUX forming the associated network (starting with the 
gateway MUX) a copy of the associated cross-connect 
map(s). As mentioned above, a cross-connect map lists 
for each data rate processed by the MUX the addresses 
of all port circuits and transmission channels supporting 
the data rate and the source to destination relationship 
(routing) between such facilities, e.g., port to port, port 
to channel, or channel to channel addressing. 

Armed with such information, the program starts to 
build a map identifying each path traversing the network 
including the addresses of all components and termina- 
tion points forming the path. The program thus proceeds 
to block 7 where it checks to see if it has completed the 
processing of the cross-connects maps that it obtained 
at block 6. If that is the case, then the program proceeds 
to block 9 (FIG. 4). Otherwise, it proceeds to block 8 
where it gets the next cross-connect entry of the map 
that it is currently processing and then proceeds to block 
8-1 . At block8-1 the program checks to see if has already 
associated a path with a component (port or channel) 
whose address is contained in the cross-map that it is 
currently processing. If yes, then the program proceeds 
to block 14. If no, then the program (block 8-2) checks 
to see if the current entry in the cross-connect map that 
it is processing (i.e., active map) contains the address of 
a termination point for a particular path, i. e. , a port circuit. 
If so, then the program (block 8-6) assigns a path name 
to that path segment and stores the addresses (port, NE, 
slot, and channel) for each component forming that seg- 
ment in local memory in association with other segments 
of the relevant path. The program (block 8-7, FIG.6)then 
checks the list of components thus far forming the rele- 
vant path to see if it contains the addresses of the termi- 
nation points for the path. If so, then the program (block 
8-8) determines that it has completed "tracing out" the 
path and stores the list, or data record, for that path in 
database 160 and then returns to block 7. If no, then the 



program (block 8-9) concludes that it has not completed 
tracing out the path end to end. I n that case then the pro- 
gram (a) identifies the physical frame slot that supports 
the outgoing channel associated with the identified port 
5 to channel path segment first, and (b) determines, from 
the information obtained earlier for that slot, the address 
of the network element connecting to the other end of 
identified transmission media. (For example, path seg- 
ment 303-1 shown in FIG. 1.) The program (block 8-10) 
io then goes on to identify the address of the incoming 
channel of the neighboring network element that is con- 
nected via the identified transmission media to the iden- 
tified outgoing channel of the network element being 
processed. The program does this using the industry 
15 standard that maps a SONET channel into a shared op- 
tical transmission facility, e.g., the identified path seg- 
ment. The address of the latter incoming channel is then 
added to the above-mentioned list of components. The 
program then returns to block 7. 

20 |f the program (block 8-2, FIG. 3) concludes that the 
list that it is building does not contain a port, then it pro- 
ceeds to block 8-3, which indicates that the path segment 
contains an incoming and outgoing channel, i.e., two 
channels, but not a port circuit. Note that blocks 8-3 

2S through 8-5 respectively perform substantially the same 
functions that are performed at blocks 8-6 : 8-9 and 8-10, 
but with respect to one or more channels (e.g., two chan- 
nels), ratherthan a port, as noted in the FIG. Accordingly, 
for the sake brevity and clarity, blocks 8-3 through 8-5 

30 will not be specifically described herein. 

If, as mentioned above, the program exits block 8-1 
via the "yes" leg and proceeds to block 14, then the pro- 
gram has recognized that one address of the current pair 
of addresses forming a respective cross-connect entry 

35 js part of a path that has been previously identified. The 
program (block 14) then notes the type of component 
whose address is the other entry of the current pair of 
addresses in the map. The program does this based on 
the format of the address, in which the format of the ad- 

40 dress of a port is different from the format of an address 
for a channel. That is, a port address contains different 
letters and numbers to distinguish it from a channel ad- 
dress. The program (block 1 5, FIG. 6) thus uses that dif- 
ference to determine if the address is associated with a 

4S port. If so, then the program (block 1 6) adds the port ad- 
dress (identity) to the path list that the program is building 
and then checks to see (block 17) if it has identified the 
end points of the path. If not, then the program returns 
to block 7 to process the next entry in the cross-connect 

so map that it is currently processing. Otherwise, the pro- 
gram (block 18) stores the entire path list in database 
160 and then returns to block 7. 

If the identified component is not a port (i.e., it is a 
channel) then the program (block 1 9) checks to see if the 

55 pair of addresses (obtained at block 8, FIG. 3)of theentry 
currently being processed are assigned to channels who 
are associated with two different named (identified) path 
segments. If so, then the program (block 20) merges the 
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identified path segments into a single path and then pro- 
ceeds to block 17 to determine if the merged segments 
contain two port circuits (end points) and thus represents 
a complete path. If the program exits via the "no" leg of 
block 1 9, then it (block 21 ) adds the identity of the chan- 
nel to the aforementioned path list and then proceeds to 
block 7 via blocks 22 and 23. It is noted that the functions 
performed at block 22 and 23 are similar to those per- 
formed at blocks 8-9 and 8-10, respectively. 

If the program exits block 7 (FIG. 3) via the "yes" leg, 
then the program (block 9, FIG. 4) checks to see if it has 
completed processing all elements forming the newly-in- 
stalled network (or a network which has changed in some 
way). If no, then the program (block 10) obtains the 
cross-connect map(s) from the network element having 
the next position in the network relative to the gateway 
element and then returns to block 7. Otherwise, the pro- 
gram (block 1 1 ) checks to see if there are still one or more 
incomplete paths whose terminations are not yet known 
by the program and exits (block 1 2) if that is not the case. 
Otherwise, the program begins the processing of 
"left-over" path segments, if any. The program processes 
each such segment by first (block 1 3) identifying the net- 
work element containing the unterminated end of the 
segment and the appropriate cross-connect map asso- 
ciated with the identified network element. The program 
then proceeds to block 25. 

The program (block 25) notes Irom the cross-con- 
nect map being processed and, particularly, the entry 
identifying the address of the channel that is at one end 
of the incomplete segment, the other address forming 
the associated pair of addresses contained in that entry. 
As mentioned above, the program does this based on 
the format of the address, in which the format of the ad- 
dress of a port is different from the format of an address 
for a channel, as mentioned above. The program (block 

26) then uses that difference to determine if the other 
address is associated with a port. If not, then the program 
proceeds to block 30 (FIG. 5). Otherwise, it adds (block 

27) the port address (identity) to the path list such that 
the identified channel is logically connected in the path 
to the identified port. Similarly, the program (block 28) 
then determines if the path contains two ports, which 
ports would represent the end points of the path. If that 
is not the case, then the program proceeds to block 24 
to process the next unterminated path segment in the 
network element identified at block 13. Otherwise, the 
program (block 29) stores the entire path list in database 
1 60 and then proceeds to block 24. 

If the identified component is not a port (i.e., it is a 
channel) then the program (bbck 30, FIG. 5) checks to 
see if the addresses of the pair of addresses of the entry 
currently being processed are associated with respec- 
tive channels who are associated with two different 
named (identified) path segments. If so, then the pro- 
gram proceeds to block 34. If the program exits via the 
•no" leg of block 30, then it (block 31) adds the identity 
of the channel to the path list and then returns to block 



24 via blocks 32 and 33. It is noted that functions per- 
formed at block 32 and 33 are similar to those performed 
at blocks 8-9 and 8-10, respectively. (It is noted that if 
the program exits via the "no" leg of block 24, then it pro- 
s ceeds to block 11 to continue its processing of incom- 
plete paths.) If the program proceeds to block 34 {FIG. 
4) then it merges the identified path segments into a sin- 
gle path and then proceeds to block 28 to determine if 
the merged segments contain two ports (end points) and 
io thus represent a complete path. 

Turning now to FIG. 7, there is shown a simplified 
block diagram of a MUX, in which a MUX comprises a 
plurality of so-called MULDEMs (MULtiplexer-DE Multi- 
plexer) 401-1 through 401 -N. A MULDEM, more partic- 
is ularly, includes, inter alia, an Optical signal to Electrical 
signal (O/E) converter 402, demultiplexer 403, switching 
fabric 404, multiplexers 405-1 through 405-j and associ- 
ated Electrical to Optical (E/O) converters 406-1 through 
406-j connected to respective optical communications 
20 paths 412-1 through 412-N. In particular, O/E 402 con- 
verts optical signals that it receives via optical transmis- 
sion medium (path) 407-1 into electrical signals for pres- 
entation to demultiplexer 403. Demultiplexer 403 demul- 
tiplexes the "high-speed" signals received over path 407 
2S into a number of "slower-speed" data streams, three of 
which, 403-1 through 403-3, are shown in FIG. 7. Such 
demultiplexing is based on the addresses of the logical 
channels associated with the incoming signals. The re- 
sult of such demultiplexing is then presented to respec- 
30 tive inputs of switch 404. Switch 404, in turn and in ac- 
cord with its associated cross-connect map, routes 
(switches) the contents of each of the data channels that 
it receives from demultiplexer 403 to an input of one of 
the multiplexers 405-1 through 405-j. (As mentioned 
55 above, a cross-connect map associates an incoming 
data port and associated circuit pack (i.e., channel ad- 
dress) with an outgoing data port and associated circuit 
pack (channel address.) Switch 404 may also route a 
data channel to some other path, such as path 41 3 ex- 
40 tending to particular CPE (not shown in the FIG.). Each 
multiplexer 405, in turn, multiplexes signals that it re- 
ceives via its associated inputs to its output terminal ex- 
tending to the input of an associated output O/E 406. The 
output O/E 406, in turn., converts electrical signals that it 
45 receives into optical signals for presentation to an asso- 
ciated optical transmission path 412, e.g., path 412-1. 

A technician initially inputs the cross-connect maps 
that control the routing of signals through MULDEMs 
401-1 through 401 -N, respectively, in the associated 
50 processor 408. Processor 408 then supplies a particular 
cross-connect map to an associated switch 404 via path 
409, e.g., 409-1 . Switch 404 then routes the signals that 
it receives in accord with the routing specified in the as- 
sociated cross-connect map. Once the cross-connect 
55 maps have been stored in processor 408, then, in accord 
with the invention, management system 150 (FIG. 1) 
may obtain copies of the maps to identify the configura- 
tion of the associated network and paths (connections) 
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that traverse the network, as discussed above. If the 
technician or OS thereafter changes a cross-connect 
map to effect a change in the routing of particular signals 
through the associated switch 404, then the associated 
processor 408 supplies the change to switch 404. Switch 5 
404, in turn, changes the routing of the affected signals. 
In addition, processor 408 communicates the change to 
its associated gateway MUX via the system overhead 
channel, represented in the FIG. by path 411. (The in- 
coming overhead channel is represented in the FIG. by 10 
path 410.) The gateway MUX, in turn, and in the manner 
discussed above ; supplies the change to system 150. 
System 150, in turn, updates the database 160 record 
affected by the change. 

Illustrative examples of such records are shown in 15 
FIG. 8. System 150 creates and stores the records in 
database 1 60 in accord with the operation of the program 
of FIGs. 2 through 6, as discussed above. Specifically, 
the records 160-1 through 160-n are associated with re- 
spective network elements and identify a particular NE 20 
(MUX) infield 161 and indicates in field 162 whether the 
NE is a gateway. Other fields of a record respectively 
characterize the equipment forming a network element, 
associated addresses and parameters (field 163). They 
also identify the paths which are routed through the net- 25 
work element (field 164). Records 180 identify such 
paths, as will be explained below. An expanded version 
of field 163 is shown in FIG. 9, and is formed from sub- 
fields 163-1 through 163-N. A subfield identifies, more 
particularly, (a) equipment type (e.g., demultiplexer, op- 30 
tical-to-electrical converter, etc.), (b) the address of the 
equipment and (c) associated parameters. Such param- 
eters specify, for example, line coding, thresholds, etc., 
and include an indication (e.g., a flag) noting whether the 
equipment connects to a neighboring NE, and if so, the 35 
identity of the neighboring equipment (port). Returning 
to FIG. 8, records 180 respectively identify the various 
paths traversing a network, e.g., network 300 (FIG. 1). 
This is done by identifying a path by its associated name 
(field 165) as specified by system 150; the address of 40 
the NE at one end of the path (field 166), the address of 
the port (field 167) and address of the circuit pack (field 
168) in that NE which terminates that end of the path: 
the channels and associated circuit packs contained in 
intervening NEs (field 169); and the address of the NE 45 
at the other end of the path (field 1 70) its associated port 
(field 1 71 ) and circuit pack (field 1 72). The following is a 
simple example of such a record: 

PATH1:NE1:PORT2:CP1c: channel A:CP1b:NE2: 
channel H:CP2a:port3:CP2c so 
and indicates that the path associated with the name of 
pathl starts at circuit pack 1c contained in port 2 of a 
network element whose address is NE 1 and leaves that 
NE via channel A associated with circuit pack 1 b and is 
received at a circuit pack 2a of network element NE2 and ss 
is then cross-connected via channel H (dropped) to a 
point external to the network via circuit pack 2c of port 3 
of NE2. A more complicated path record would be simi- 



larly interpreted. 

The foregoing is merely illustrative of the principles 
of the invention. Those skilled in the art will be able to 
devise numerous arrangements, which, although not ex- 
plicitly shown or described herein, nevertheless embody 
those principles that are within the spirit and scope of the 
invention. For example, it is apparent that the claimed 
invention may be used in other types of networks, such 
as cable and wireless networks. 



Claims 

1 . A method of operating a network management sys- 
tem, said network management system supporting 
the operations of an associated network comprising 
a plurality of network elements interconnected via 
respective communications paths, said method 
comprising the steps of 

responsive to a change in said network, iden- 
tifying each of said network elements, 

obtaining from each of the identified network 
elements information indicative of at least (a) iden- 
tities of components forming the network element, 
(b) identities of neighbor network elements and (c) 
configuration of the network element, and 

determining from the information obtained 
from each of the identified network elements the 
interconnections between network elements and the 
configuration of said network, in which said network 
may be one of a plurality of different network config- 
urations. 

2. The method of claim 1 wherein said step of obtaining 
includes the step of communicating with a gateway 
network element to obtain said information, and 
wherein said information includes a cross-connect 
map associated with a respective data rate. 

3. The method of claim 2 wherein said step of commu- 
nicating includes the step of supplying a password 
associated with said gateway and the address of 
said gateway to said network management system 
so that said network management system may com- 
municate with said gateway via a communications 
path connecting said network management system 
to said gateway. 

4. The method of claim 1 wherein said step of deter- 
mining includes the step of determining each com- 
munications path established via individual ones of 
said network elements, in which opposite ends of a 
communications path terminate at port circuits 
respectively associated with said network elements. 

5. The method of claim 1 further comprising the step 
of storing said information in memory in association 
with the identity of the respective network element. 
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6. The method of claim 5 further comprising the step 
of determining which components of an associated 
one of the identified network elements are idle are 
which components are in use. 

5 

7. The method of claim 5 further comprising the steps 

receiving other information indicative of an 
alarm condition from said network, in which said 
alarm is associated with one of said network ele- 
ments, and w 

determining the cause for the alarm condition 
as a function of said stored information. 

8. The method of claim 1 wherein said step of deter- 
mining includes the step of building a map defining is 
each communications path established by said net- 
work, in which each such path is defined by the 
addresses of the network elements that establish 

the path in said network. 



9. The method of claim 1 wherein each said network 
element is a lightwave multiplexer. 



20 



10. The method of claim 1 wherein said plurality of dif- 
ferent network configurations include a hub network 2S 
and ring network. 

11. The method of claim 1 wherein said information 
includes cross-connect maps associated with 
respective data rates. 30 

12. The method of claim 1 further comprising the step 
of creating a model of said network, in which said 
model comprises at least a data record for at least 
each circuit, transmission channel and network ele- 35 
ment forming said network. 

13. The method of claim 1 further comprising the step 
of identifying each transmission path traversing said 
network via respective ones of the network elements 40 
and connections. 
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FIG. 2 



CM 



GET ADDRESSES OF (a) NE's FORMING THE 
PERTINENT NETWORK, (b) NEIGHBORING NE's 

AND (c) CIRCUIT SLOTS USED TO CONNECT 
TO THOSE NEIGHBORS 



OBTAIN FROM ALL OTHER NE's THAT SHARE THE 
PERTINENT NETWORK, THE ADDRESSES OF THEIR ■ 
NEIGHBORS AND ADDRESSES OF THE CIRCUIT SLOTS 
USED TO CONNECT TO THOSE NEIGHBORS 



STORE INFORMATION IN DATABASE 



TRACE NE TO NE CONNECTIVITY TO 
IDENTIFY THE CONFIGURATION OF THE 
ASSOCIATED NETWORK. ASSIGN AND STORE 
A RELATIVE POSITION TO 
EACH NE IN THE NETWORK 



FOR EACH NE IDENTIFY CIRCUIT SLOTS AND 
PORTS THAT DO NOT CONNECT TO A NEIGHBOR 



I 



GET CROSS-CONNECT MAPS FROM GATEWAY NE y ~ 6 
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FIG. 3 



FROM FIG. 2 & 4 & 6 



7 



ALL PORTS AND CHANNELS 
IN THIS NE EVALUATED ? 
♦ NO" 



JES 



TO FIG. 



GET NEXT CROSS-CONNECT ENTRY 
I 



DOES THE CROSS-CONNECT ENTRY 
CONTAIN A CHANNEL ID THAT IS 
v ALREADY PART OF A NAMED PAT H ? 
{NO 

DOES THE CROSS-CONNECT LIST 
ENTRY CONTAIN A PORT 
(SOURCE OR DESTINATION) ? 




TO FIG. 

© 

i 



1 



14 



IDENTIFY THE COMPONENT 
HAVING THE OTHER ADDRESS 
OF THE ENTRY PAIR 



THE PATH PASSES 
THROUGH THE NE 




NO 



THIS NE 
CONTAINS AT 
LEAST ONE PATH 



ENDPOIN 



ASSIGN A PATH NAME AND STORE THE 
KNOWN COMPONENTS IDENTIFIED THUS FAR 



USE THE PATH'S "OUTGOING" AND 
"INCOMING" CHANNEL IDs TO IDENTIFY THE 
SLOTS USED TO CONNECT TO THE TWO 
NEIGHBOR NE's AND THUS IDENTIFYJHE 
NEIGHBOR NE's ADD TO THE PATH'S LIST 



'/TERMINATION 
8-3 



•8-4 



ASSIGN A PATH NAME 

AND STORE THE 
KNOWN COMPONENTS 
IDENTIFIED THUS FAR 




8-6 



USE STANDARD SONET CHANNEL MAPPING 
TO DETERMINE THE TWO NEIGHBOR NE's 
"INCOMING" CHANNEL IDs. ADD THE 
NEIGHBOR NE's CHANNEL IDs TO 
THE PATH LIST 



8-5 
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FIG. 4 



FROM FIG. 3 



i 



9 



ALL NEs EVALUATED ? 




NO 



YES 



JL 



10 



OBTAIN THE CROSS-CONNECT MAPs 

OR THE NEXT NE BASED 
ON THE RELATIVE POSITIONS OF 
THE NE IN THE NETWORK MODEL 



JL 



11 



ARE THERE INCOMPLETE/ 
UNTERMINATED PATHS ? 
fYES 



NO 




1 



12 



FROM THE LIST OF INCOMPLETE PATHS, 
IDENTIFY THE NEIGHBOR NE AT THE 

UNTERMINATED END OF A PATH, AND 
OBTAIN ITS CROSS-CONNECT MAPs 
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27 



IDENTIFY THE CHANNEL'S 
CROSS-CONNECT DESTINATION, 
i.e., CHANNEL OR PORT 

t ~ 

IS THE CROSS-CONNECT 
DESTINATION A PORT ? 
♦ YES 



,N0 




TO FIG.5 



FROM FIG.5 



ADD THE PORT ID 
TO THE PA TH'S LIST 



29 



DOES THE PATH LIST 
CONTAIN TW O PORT IDs 




MERGE THE PATH NAMES 



J 



34 



TERMINATE THE PATH 
LIST AND STORE IT 



FROM FIG.5 



YES. 



ARE THERE INCOMPLETE 
PATHS WITH A CHANNEL 
IN THIS NE ? 

[ NO 
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FIG. 5 



TO FIG.4 



FROM FIG.4 




I 



DOES THE ENTRY CONTAIN 
TWO CHANNEL IDs THAT ARE 
PART OF TWO DIFFERENT 
NAMED PATHS ? 




NO 



ADD THE CHANNEL ID 
TO THE PATH'S LIST 



USE THE PATH'S OUTGOING" 
CHANNEL ID TO IDENTIFY THE 
SLOT USED TO CONNECT TO THE 
NEIGHBOR NE AND THUS IDENTIFY 
THE NEIGHBOR NE ADD TO 
THE PATH LIST 



TO FIG.4 



USE STANDARD SONET CHANNEL 
MAPPING TO DETERMINE THE 
NEIGHBOR NE's "INCOMING" CHANNEL, 
ADD THE NEIGHBOR NE's CHANNEL 
TO THE PATH LIST 
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management system may then use the contents of the 
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ers, for example, a request for additional transmission 
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by a trouble alarm. Further, the network management 
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